The “embedded environment” concept usually means a combination formed by processor-based equipment and software, which is arranged to function as a part of some larger system configuration. Usually they are designed to be as simple as possible and they do not often include e.g. any mass storage components or peripheral devices in general. Many embedded systems are fitted e.g. into automatic vending machines of different kinds, of which beverage vending machines are mentioned as an example.
Connecting devices based on embedded systems to the Internet and all networking of such devices in general offers many possibilities for increasing the intelligence of remote devices and a better ability to fulfil the requirements of their users and their administration.
Innumerable examples may be mentioned of application areas for such networked embedded systems, from the HPAC systems and simple energy consumption measurements of real estate to large equipment and alarm systems. For example, it is known from copying machines to utilise embedded systems to detect their operational state. Networking of embedded systems will hereby allow e.g. their remote control, remote analysing and remote management.
Known solutions for the outgoing and incoming data transfer of remote devices based on embedded systems are represented by utilisation of such simple data transfer interfaces taking place at hardware level, through which it is possible to report e.g. on the need for maintenance of the remote devices or on the need for supplementation of their sale products.
However, more complex administration applications represent a real challenge to embedded systems. Since embedded systems are often implemented as advantageously as possible, so that they lack e.g. data storage capacity on a large scale, such known data transfer methods are avoided, which are in general use in computer networks, and in their place much simpler protocols are in general use, which operate at hardware level.
The administration and status monitoring of an embedded remote device, such as e.g. a beverage vending machine, are presented as an example of such a simple mode of operation utilising data transfer protocol at hardware level.
According to the state of the art, the functionality of a beverage vending machine is often arranged in such a way that a processor unit is arranged for the remote device, which usually is a micro controller and storage media. In the storage media are stored i.a. the software required for the management, monitoring and operation of the beverage vending machine.
When information is desired e.g. about the beverage vending machine's degree of fullness, a monitoring call can be made to the beverage vending machine at the operator end of the monitoring system. In consequence of this a data transmission link is set up through the data network, such as e.g. a telephone network, to the server machine of the operator end. When the link has been successfully established between the parties, a data transmission procedure of several different steps follows, wherein data is transmitted from the remote device to the server machine and possibly back.
When data transmission takes place between the parties, e.g. in serial form, a serial link is first opened from the beverage vending machine and information on the successful establishment of the link is relayed to the server at the operator end. When the server has ascertained the bit string depicting the open state of the link, a transmission takes place through the data network from the beverage vending machine's memory registers of values necessary for finding out the current status of the beverage vending machine, based on which values the server machine will find out the answer to the matter of the request. During the time when the line is open much data transmission then follows in various steps between the remote device and the server machine inquiring about its status.
In the solution of the described kind the size of the transmitted data is not very big (a few tens—hundreds of bits), but the traffic back and forth will cause varying loading in the network and will bring about a certain uncertainty for the data transmission, because the data transmission takes place in individual pieces independently of each other. Furthermore, the described manner of data transmission may require, for example, a circuit-switched data transmission network (e.g. a line telephone connection), which is often very difficult to arrange for the remote device.
Furthermore, the ability to update the application programmes arranged for the remote devices will be very difficult, both technically and quantitatively. When need arises to update the programme of the remote device, each remote device must be visited for taking measures in order to update a new software version or even to install a new application module. In more advanced versions it may be possible by way of the data network to download such a special update packet separately for each remote device, which replaces the old software version. If there are numerous remote devices and different versions for these, updating of the software will become even more difficult.
The application development of remote devices is also difficult, since their application code is usually a micro controller-based native language. Hereby they are machine language, which the processor can interpret directly, such as an assembler, the editing and further developing of which is especially difficult and requires much studying of programming and e.g. knowledge of the fixed data transmission protocols used in each case.
What is characteristic in the solution of the described kind is that its functionality is arranged in a fixed manner at the remote device. If it is not especially critical in terms of time to bring about the functionality, then it can also be arranged at the server machine, but the data transmission will strongly take place in the described manner at hardware level.
In more advanced operational modes, downloading of remote functionality is done by using a native code at hardware level. However, without e.g. a complete remote file management system it is hereby difficult to achieve a seamlessly changing functionality during dynamics and processing. In addition, the references relating to data transmission are arranged to be fixed in the application code proper.
U.S. publications U.S. Pat. No. 6,134,600 (Liu), U.S. Pat. No. 5,991,795 (Howard et al.) and U.S. Pat. No. 6,219,677 (Howard) present more advanced methods for solving the situations described above.
U.S. publication 6,134,600 (Liu) describes a solution, wherein remote devices are offered application tools located at the server machine in a Common Object Request Broker Architecture, that is, in a CORBA customer-server architecture. The remote device is hereby allowed access to tools located at the server machine without revealing their relating functionality. At the server machine, where the system's functionality is essentially arranged, JAVA applets are maintained. The remote devices relay parameters required for the analysis to the server machine, wherein the JAVA applets will process the desired analysis. Then the answer is returned to the remote device. The described solution is WEB-based and it strongly bound to a data network according to the TCP/IP protocol.
U.S. publication 5,991,795 (Howard et al.) also presents a data transmission protocol and a method especially for exchanging information in embedded systems over a data network. This solution, too, is characterised by use of the HTTP protocol. Such methods based on presenting languages, such as e.g. JAVA applets according to HTML, are used in interaction situations aimed directly at the end user. JAVA applets cannot actually be linked up with a native application code and they are not either dynamic. Further, the locations of applets are always attached to a defined HTML page and their execution requires a relatively efficient processor and hardware, whose sizes are minimised as far as possible in the embedded environments.
It is known in JAVA profiles, such as J2ME (Java 2 Platform, Micro Edition) to define references for downloading of remote application. However, offering of these to remote devices and their chaining to one another is not defined. Functionality as the JAVA interface with a native code is standardised to be fixed in each profile, so under these circumstances it is not application-specific.
CORBA, which was already mentioned in the foregoing, is the core of the network operating system defined by the OMG organisation. It makes possible compatibility of data transmission between different hardware and operating system platforms and data networks from the smallest micro controllers to the most efficient micro processors. The ORB operating system core in accordance with the CORBA architecture carries out the format change required between different operation environments, whereby that part of the data is filtrated away at the same time, which is inessential to the environment used by the receiving party.
The ORB core based on CORBA seeks implementation of the service requested by the customer, converts and transfers the parameters relating to the service, activates implementation, if required, and transfers the control to the service object. After performance of the service, ORB will return any results there may be to the customer formatted according to his environment.
From JAVA an own ORB RMI (Remote Method Invocation) built into JAVA is also known, which corresponds with the ORB concept of CORBA. However, RMI is only an expansion of the language, so it will not function with objects made in other languages. JAVA will thus remove the borders between hardware environments, but it will bind to a certain programming language.
However, an attempt can be made to solve this limitation with JNI (JAVA Native Interface). JNI makes it possible to call also other components (for example, C, C++) made in other languages from JAVA and vice versa. However, JNI for its part binds the programme strongly to a certain hardware architecture.